In a runtime environment, an executable software node may need the services of, and thus may need to communicate with, another executable software node. Generally, an executable software node is a set of software instructions that, when executed, perform one or more functions. Examples of executable software nodes include software applications such as word processors and web browsers, and include software add-ins such as spell checkers and web-browser toolbars.
As an example of one executable node needing to communicate with another executable node, when a user of a word processor invokes a spelling tool to obtain a correct spelling of a word, the word processor may call a spell-checker add-in to perform this service, in which case the word processor and the add-in need to communicate with one another. The user may invoke the spelling tool via the word processor's drop-down menu, and in response to this invocation, the word processor makes a software call to the spell-checker add-in. Next, the word processor transfers to the add-in the word for which the user wants the correct spelling. After determining the correct spelling of the word, the add-in sends the correctly spelled word back to the word processor, or sends an indication to the word processor that the word is spelled correctly.
To give a first executable node the ability to communicate with a second executable node, one typically designs the first executable node to have the same interface view (hereinafter shortened to “view”) as the second executable node. A view of an executable node is itself an executable software node, e.g., an application programming interface (API), via which the executable node can communicate with another executable node. Therefore, designing the first executable node to have the same view as the second executable node allows the two executable nodes to communicate with one another via a common view. For example, designing a spell-check add-in to have the same view as a word processor allows the add-in to communicate with, and thus to “work” with, the word processor.
Executable software nodes are sometimes updated with such frequency and on such unpredictable schedules that it may be difficult to ensure that the current version of a first executable node will always have the same view as the current version of a second executable node that is designed to work with the first node. For example, a software provider may update a word processor on an unpredictable schedule that is partially driven by the need to resolve unforeseen compatibility issues, and some of these updates may involve a change to the view. Consequently, there may be periods during which an add-in designed for the word processor does not work with the current version of the word processor because the add-in provider has yet to update the add-in's view to be compatible with the word processor's new view.
Unfortunately, if a current version of a first executable node does not have the same view as, and thus does not work with, a current version of a second executable node designed to work with the first node, then the current version of the first node is not “backwards compatible” with the current version of the second node. Such lack of backwards compatibility may reduce the number of users who update to the current version of the first node, and thus may reduce sales of the first node. For example, suppose that the current version of a word processor is not backwards compatible with, and thus does not work, with the current version of a particular spell checker. If a user of the word processor wants to retain the ability to use the spell checker, then he may forgo updating to the current version of the word processor, at least until a compatible version of the spell checker is released.
One way to eliminate periods during which a first executable software node is not backwards compatible with a second executable node that is designed to work with the first node is to simultaneously release the latest versions of the first and second nodes.
But unfortunately, simultaneously releasing the latest versions of the first and second software nodes is often impractical, particularly where the first and second nodes are developed by different software providers.